REMARKS 



The above amendment and these remarks are responsive to 
the Office action of 3 Aug 2004 of Examiner Sathyanaraya R. 
Pannalla . 

Claims 1-16 are in the case, none as yet allowed. 

Drawings 

The amendments proposed by applicants to the drawing 
Figures 3, 15, 16, and 17 filed on 4/19/2004 have been 
approved by the Examiner. Corrected drawings have been 
ordered and will be forwarded to the Commissioner as soon as 
available . 
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Speci fi ca ti on 



The specification has been objected to for the use of 
the trademark EDI at page 43, line 18. 

Applicants have amended the specification and claims to 
remove references to EDI, replacing it with "electronic data 
interchange (EDI)" wherever found, making clear that it is 
used as an acronym. The term "electronic data interchange" 
is abbreviated in the art as EDI, which is used in the 
original specification at page 43, line 18. See McDaniel, 
George, Ed. IBM Dictionary of Computing , McGraw-Hill, Inc., 
New York, 10th Ed. Aug. 1993. vii # 228. McDaniel states at 
page 22 8 "EDI Electronic data interchange. (T)", where the T 
indicates (at page vii) that the source of the acronym is 
working papers being developed by ISO/IEC JTC1/SC1. See 
also, Wiecha, U.S. Patent 5,870,717 (cited by the Examiner 
in the present case) , which further clarifies that the term 
EDI is well known in the art, stating at Col. 14, lines 58- 
63 : 

"The Electronic Data Interchange (EDI) is a standard 
for the exchange of business data. It defines: 
Communication wrappers, which are usually handled by a 
communication package from a Value Added Network (VAN) 
providing EDI mailboxes...." 
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35 U.S.C. 112 

Claims 1 and 11 have been rejected under 35 U.S.C. 112, 
second paragraph, with the statement, "Applicant need[s] to 
correlate terms used in the amended claims with respect to 
the specification." The Examiner has not specified which 
terms are objectionable. In claims 1 and 11 the only terms 
added by the amendment were : 

"electronic data interchange" 

This term is abbreviated in the art as EDI, which 
is used in the original specification at page 43,. 
line 18. See McDaniel, George, Ed. IBM Dictionary 
of Computing , McGraw-Hill, Inc., New York, 10th 
Ed. Aug. 1993, vii, 228. McDaniel states at page 
228 "EDI Electronic data interchange. (T) " , where 
the T indicates (at page vii) that the source of 
the acronym is working papers being developed by 
ISO/IEC JTC1/SC1. 

"relational database" 
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This term is used throughout the original 
specification. See for example page 16, line 3. 

Claims 5, 8, and 13 have been rejected under 3 5 U.S.C. 
112 for improper use of trademarks. 

Applicants have not used the term "EDI" as a trademark, 
but have used it as an acronym meaning "electronic data 
interchange" which those of skill in the art will recognize 
refers to electronic data interchange as that term is used 
in the draft ISO specifications such as that referred to 
above by McDaniel and Wiecha. Applicants have amended 
claims 5, 8, and 13 to replace the use of EDI with 
"electronic data interchange" . 

Applicants urge that the rejection of claims 1, 5, 8, 
11, and 13 under 35 U.S.C. 112 be withdrawn. 

35 U.S.C. 103 

Claims 1, 11 have been rejected under 35 U.S.C. 103(a) 
over Wiecha (US Patent 5,870,717) in view of Abrams (US 
Patent 6, 151, 608) . 
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Claims 2-10, 12-16 have been rejected under 35 U.S.C. 
103 (a) over Wiecha in view of Anderson (US Patent 
6,360,211) . 

Applicants traverse the rejections under 35 U.S.C. 103, 
and argue that the Examiner has not established a prima 
facie case of obviousness, the legal basis for which was set 
forth in the prior Amendment . 

Applicants argue that when the claims are properly 
understood, and the references properly applied, the 
required prima facie case is not made. 

Claims 1 and 11 

With respect to claims 1 and 11, applicants note that 
the Weicha invention encompasses the scope of loading a 
catalog EDI into a DB2 table to be used by an online 
ordering system. 

Applicants' invention as set forth in these claims, 
however, goes beyond that, delving specifically into the 
ability to load that catalog into a staging area and 
allowing certain special users access to make carefully 
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controlled changes to that data. In applicants invention, 
not all of the data is changeable, the structure of the 
staging table and the surrounding system actually controls 
what can be changed once the vendor has supplied the 
information. Applicants invention does receive a file from 
a supplier via EDI. However, the distinction with respect 
to Weicha and Abrams lies in what applications do with it. 
Claim 1 is set forth and analyzed as follows, which analysis 
also applies to claim 11: 

1. A method for publishing a catalog as a relational 
database production table , comprising the steps of: 

receiving from a supplier by electronic data 
interchange a flat file catalog; 

The Examiner cites Wiecha Fig. 1, 6, col. 3, lines 
10-17, lines 59-61, and col. 14, lines 59-60. 
Applicants demur. 

loading said flat file catalog into a relational 
database staging table; 
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relational database tables but does not teach 
explicitly loading data into relational database 
tables." The Examiner then cites Abrams, Fig. 4, 
col. 12, lines 6-22. 



"There are two approaches to loading the data 
into a temporary table depending on whether 
the source data is in an ASCII file or 
whether it resides in another Oracle table. 
For data originating from a non-Oracle 
source, the invention provides a format for 
an ASCII file into which the user can extract 
data from a non-Oracle source and use 
SQL*Loader to insert the data into an Oracle 
temporary table. Before this invention, the 
user had to write validations, translations, 
and change the format of the data as part of 
coding the SQL*Loader script. Using the 
invention, however, the user only needs to 
create an extract table and dump it into the 
temporary Oracle table. For source data 
orginating in an Oracle table, the invention 
uses an automatic upload process to load the 
source table to the temporary table. The 
format and characteristics of the data in the 
temporary table do not matter since the 
invention will later reformat the data to fit 
into the destination table." (Col. 12, lines 
6-22 . ) 

Applicants traverse the Examiner's reading of 
Abrams on the claim, noting that Abrams is loading 
data from a supplier into a temporary table, whose 
format is unimportant. In applicants case, as is 
stated later in this claim, the format of the 
staging table is very important : it matches that 
of the production table. Abrams also indicates 
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that the only purpose of the temporary table is to 
allow mapping programs to then move the data into 
the production table. The purpose of the staging 
table in applicants invention is to allow manual 
intervention, update and validation before the 
data is moved into the production version of the 
table . 



allowing buyer audit control over selected fields in 
[ [the] ] said staging table catal og while restricting 
buyer access to other fields; 

The Examiner cites Wiecha Fig. 12, col. 9, lines 
2-10. Wiecha teaches: 



"This function [Order Manager and Catalog 
Browser] runs on the end-user's personal 
computer. . . It provides the following main 
function to an employee using the system..." 
(Col. 8, lines 25-29) 

"Product Clip Board 



"Select items on Product Listing for 
adding to clipboard. 

"Add item on Product Page to clipboard. 
"Delete an item in the clipboard. 
"Change the quantity of an item in the 
clipboard . 

"Change the quantity of an item in the 
clipboard. 

"Clear the clipboard to remove ALL 
items . 
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"Save the clipboard (to a file) . 
"Submit the clipboard (as a purchase 
request) . 

"Show the items on the clipboard. 
"View clipboards (i.e. saved clipboard 
files). (Col. 9, lines 1-10). 

Applicants traverse this reading of Wiecha. Here, 
Wiecha is describing the activities of an employee 
user, not those of a "buyer", as applicants claim. 
There is no teaching here or elsewhere in Wiecha 
of allowing a buyer edit access to selected fields 
in a staging table catalog and restricting access 
to other fields. As is clearly set forth in the 
preamble of claim 1, applicants are here claiming 
the publication (that is, creation) of the 
catalog, not just its use, as is being described 
by Wiecha. Applicants' specification renders this 
claim clear on this point: the claimed "buyer" is 
not the "requester" or, as the Examiner's citation 
of Wiecha is teaching, the "user". Thus, 



"In building a requisition catalog for a 
large enterprise with many suppliers, an 
automated process is needed to receive a flat 
file from a supplier for review by a buyer 
before being externalized for use by 
requesters . While the buyer must be able to 
review the contents, he must be restricted 
from making changes to certain sensitive 
fields, such as changing a unit price or a 
unit of measure, both of which could 
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constitute fraud. Consequently, allowing the 
buyer to edit the flat file can't provide the 
level of security required. There is a need 
in the art to provide a buyer a means of 
auditing catalog content before externalizing 
it to production for access by requesters . " 
(Specification, page 4.) 

"Referring to Figure 15, a system 
architecture for implementing catalog 
administration includes a requester browser 
410, a buyer browser 412, with net. data 
connections 391 and 393 to a dedicated DB2 
server and DB2 database 3 90 having a staging 
table 3 92 and a production table 3 94 through 
network dispatcher 102 and Go cluster 104... 

"A buyer 412 accesses staging table 392 
via net. data connection 3 91, and a requestor 
410 accesses the production 394 table via 
net. data connection 3 93. This connection 
3 91, 3 93 is implemented as a single path, and 
the requester and buyer provided different 
levels of authority to access different 
tables 3 92, 3 94 in DB2 3 90 over that same 
path. Buyer 412 can change selected fields in 
the staging table 3 92 and can update 
production table 394 from staging table 392. 
Requester 410 can only view (not change) the 
production table 394... 

"In operation, catalog flat file 314 is 
received by application server 114 through 
firewall 380 via EDI and loaded into DB2 
database 390 by application program 384. 
Catalog administration function 386 
[provides] specific users 400 audit control 
over certain fields in staging table 392, and 
publishes the catalog data to the live, or 
production, system 394. Function 386 
presents to buyer 400 a staging table 392 
with a GUI front end, with selected fields 
enable and other fields not enabled to be 
personalized. 

"Catalog file 314 is a flat file 
containing catalog items in a column 
delimited format specified to supplier 300 
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by the enterprise. 



"Application server 114 manages database 
3 90 containing staging table 3 92 and 
production table 394. A catalog file 314 
comes to application server 114, which 
includes a program 3 84 for moving data from 
that flat file to staging table 392. See 
Table 7. 

"A buyer at terminal 400 accesses the 
staging table 392 on the web 396. He views 
catalog items and enters transactions with 
action button which transfers information 
from staging table 3 92 to production table 
394. Production table 394 is referenced by 
req cat web 388, and staging table 392 is 
referenced by the catalog administration 
function 386 operated by the buyer 400. 
Typically, a buyer is member of procurement 
organization with responsibility for 
negotiating deals with suppliers. A 
requester 402 accesses production table 394 
over web 3 98 to create and submit a 
requisition to SAP 382. (Specification, 
pages 40-42, emphasis added.) 



updating a relational database production table from 
said [ [a] ] relational database staging table, said 
staging table and said production table having matching 
formats; and 



The Examiner cites Wiecha, Fig. 11, col. 7, lines 
8, which states: 



"Distribution Manager Responsible for. . . 
Update DB2/2 Tables." 
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Applicants traverse this reading of Wiecha. There 
is no teaching here of updating a relational 
database production table from a relational 
database staging table. As claimed, the staging 
table is one into which a flat file customer 
catalog has been loaded, and to which the buyer 
has access to certain fields and no access to 
others . 

allowing a user read access to said relational database 
production table . 

The Examiner cites Wiecha, col. 9, lines 25-29, 
which states: 

"Print Clipboard: This function is in 
addition to, and separate from, the report 
generation functions which use DB2/2 report 
generators. It enables users without access 
to DB2/2 to print a clipboard or submitted 
order from their own workstations." 

Applicants demur. 
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Claim 2 

With respect to claim 2, Weicha is not clear about the 
extent of his catalog maintenance functions. It appears 
that catalogs can be grouped. Applicants invention controls 
access to specific catalogs by specific personnel, controls 
changes to the data sent by the vendor, and protects some 
data sent by the vendor from being changed. Anderson speaks 
only of saving data (in this case, invoice data) from a flat 
file into an intermediary database. There is no mention 
made of data manipulation that is made to it while it is 
there, or how changes to that data are controlled. 

Applicants' claim 2 states: 

2, [Original] A requisition catalog administration method 
for providing control, audit, and publishing procedures for 
flat files received from suppliers, comprising the steps of: 

receiving a catalog flat file from a supplier; 

The Examiner refers to Wiecha, Fig. 1, 6, col. 3, 
lines 10-17, lines 59-61 and col. 14, lines 59-60. 
As with claim 1, applicants demur. 
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converting said flat file into a staging table having 
access control list controls over fields within said 
staging table; 



The Examiner cites Wiecha at Fig. 12, col. 9, 
lines 2-10, col. 8, lines 35-36, which with the 
introductory material at col. 8, lines 25-29) 
states : 



"This function [Order Manager and Catalog 
Browser] runs on the end-user's personal 
computer. . . It provides the following main 
function to an employee using the system..." 
(Col. 8, lines 25-29) . 

"Additional Order Manager functions may be 
enabled or disabled based on the login 
profile." (Col. 8, lines 35-36). 

"Product Clip Board 

"Select items on Product Listing for 
adding to clipboard. 

"Add item on Product Page to clipboard. 
"Delete an item in the clipboard. 
"Change the quantity of an item in the 
clipboard . 

"Change the quantity of an item in the 
clipboard . 

"Clear the clipboard to remove ALL 
items . 

"Save the clipboard (to a file) . 
"Submit the clipboard (as a purchase 
request) . 

"Show the items on the clipboard. 
"View clipboards (i.e. saved clipboard 
files). (Col. 9, lines 1-10). 
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Applicants traverse the Examiner's reading of 
Wiecha. That is, Wiecha is silent on the concept 
of access control list controls over fields within 
a staging table, referring only to a login profile 
-- which is not an access control list on fields 
as applicants claim. Applicants teach what an 
access control list is in their specification, as 
follows : 



"A requisition catalog for use in a web 
environment requires a very large database, 
such as an IBM DB2 database, and the 
functionality provided by, for example, a 
Lotus Notes server. However, a Lotus Notes 
access control list (ACL) can not be used 
control access to an IBM DB2 database, and 
the privileges on a DB2 table can be granted 
only by the table instance owner. 
Additionally, since Notes agents which access 
DB2 are running from a Notes server, the 
Notes server ID often has full access to all 
tables, and there is no way to limit that. 
That is, in a hybrid (Notes/DB2) environment, 
the user ID which accesses DB2 tables is the 
ID of the Notes server. Therefore, can't 
restrict access by a user to the DB2 tables. 
There is a need in the art for a system and 
method which allows certain users access to 
certain data in certain selected tables. 
That is, there is needed a system and method 
for providing very flexible access to DB2 
tables without requiring database 
administrator (DBA) involvement to issue 
grants against the tables, and bypassing the 
problem caused by Notes agents all coming 
from the same user (the Notes server ID) ." 
(Specification, page 5.) 

"Everything in Lotus Notes, even code, 
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is in documents which require access control 
list (ACL) controls on access. Consequently, 
the preferred embodiment of the invention 
uses Notes ACLs to access code. However, 
when accessing data, a role table 420 (see 
Figure 19) is used to build roles and 
permissions, and an object model is provided 
to generically access data from database 210, 
thus extending Notes, to access a non-Notes 
data source 210. In order to configure DB2 
to work in a Notes application environment, a 
single sign off is provided after getting 
through Notes code ACLs. This does not 
involve use of any of DB2 ' s role tables and 
grants, but rather a single web ID 434 known 
to the Notes code to access the DB2 data." 
(Specification, page 47.) 



controlling through a graphical user interface edit 
access authority to said staging table and through said 
access control list access to fields within said 
staging table; 



The Examiner cites Wiecha Fig. 12, col. 9, lines 
2-10, and col. 8, lines 35-36. These are set 
forth above with respect to the previous claim 
clause . 



Applicants traverse. Wiecha speaks only of a log 
in profile, and has nothing to teach about edit 
access authority to a staging table together with 
access control list access to fields within the 
staging table. 
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responsive to input from a buyer granted access control 
list access to selected field in said staging table, 
updating said selected fields; and 

The Examiner cites Wiecha Fig. 11, col. 7, line 8, 
which states: 

"Update Db2/2 Tables." 

Applicants traverse. Wiecha does not teach a 
staging table upon which access control list 
control of access to selected fields is provided. 

responsive to buyer command, updating a production 
catalog with said staging table for read access by 
users in creating requisitions against said catalog. 

The Examiner cites Wiecha, Fig. 11, col. 6, line 
2 9 to col. 7, line 8. Applicants traverse. 
Again, Wiecha does not teach a staging table 
having the characteristics recited previously in 
this claim. 
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Claim 3 

With respect to claim 3, Weicha is vague in describing 
the extent of control which the system has over the 
administrators. The administration function which he 
describes in Col. 12, lines 16-23 involves maintenance of 
EDI vendor information, not of the content of the catalog 
from the vendor. Col. 5, lines 34-47 describe manipulation 
of images and text, but no controls over what can be 
modified and what is protected. Anderson does teach storing 
flat file data into a database table, but again, there is no 
mention of data manipulation that is made to it or how 
changes to that data are controlled. 

Applicants claim 3: 

3. [Currently amended] System for building and using a 
web catalog, comprising: 

a supplier catalog flat file for storing catalog items 
in an enterprise defined format; 

The Examiner cites Wiecha Fig. 1, 6, col. 3, lines 
10-17, lines 59-61 and col. 14, lines 59-60. 
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Applicants demur. 



a database including a staging table and a production 
table; 



The Examiner cites Anderson Fig. 1, 4, col. 3, 
lines 30 and col. 18, lines 46-51, which state: 



"Invoice collector 48 extracts the invoice 
information from the flat file and stores the 
information in an intermediary database 66 
via a communication path 65, e.g., the 
internal bus of a mainframe." (Anderson, 
col. 3, lines 28-31.) 

"In a second embodiment, the present 
invention employs a non-distributed 
architecture, in which the intermediary 
database 66, customer databases 86, 
communication paths 68, 82 and 85, and 
communications interfaces 80 and 84 of Fig. 1 
are replaced with a single centralized 
database 104, as depicted in Fig. 4." 
(Anderson, col. 18, lines 46-51.) 



Applicants traverse. While intermediary database 
66 may be considered a staging table, it does not 
have the characteristics of a staging table set 
forth later in the claim. 



an application server for receiving, converting and 
storing said flat file to said staging table; 
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The Examiner cites Anderson Fig. 3, col. 17, lines 
66-67, which states: "Middleware server 114 is 
connected to mainframe 110." Applicants travers, 
noting that the citation from Anderson is silent 
as to the operation of middleware server 114, only 
stating that it is connected to mainframe 110. 

an administration function for controlling content of 
catalog information from a vendor stored to said 
staging table from said flat file ; 

The Examiner cites Wiecha Fig. 7, col. 12, lines 
16-23, which states "This is to enable the 
purchasing administrator to maintain the EDI 
vendor addresses for confirmation of shipment and 
billing, as well as status updates. The supported 
functions include..." Applicants agree that 
Wiecha has an administration function, but not one 
which controls content stored to the staging table 
from the flat file. 

a catalog administration procedure for presenting said 
staging table to said catalog administration function 
in a graphical user interface with fields of said 
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staging table selectively enabled or disabled for 
auditing in accordance with the role and authority of a 
user of said administration function; 

The Examiner cites Wiecha Fig. 7, col. 11, line 4, 
which states: "Order Manager Administration". 

Applicants traverse, noting that here Wiecha 
teaches nothing about presenting a staging table 
in a GUI with fields selectively enabled or 
disabled as recited in the claim. 

and for publishing an administration audited 
catalog to said production table; 

The Examiner cites Wiecha Fig. 8, col. 5, 
lines 34-47. Applicants demur. 

a requisition creation function operable by a user for 
creating a requisition with reference to said 
production table; and 

The Examiner cites Wiecha Fig. 3-4, col. 3, lines 
10-47. Applicants demur. 
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a web catalog function for presenting said production 
table to said requisition creation function. 

The Examiner cites Wiecha Fig. 3, col. 3, lines 
10-13. Applicants demur. 

Claims 4-7 

These claims 4-7 all depend from claim 3, and are 
distinguished from Wiecha and Anderson as discussed above 
with respect to claim 3 . 

Further with respect to claim 4, in Anderson, ACH PPD 
is a type of invoice information, not a flat file format. 
See Col. 3, lines 16-20. 

Further with respect to claim 5, applicants again note 
that Anderson does not have a Col. 23. Applicants request 
that the Examiner identify the teaching on which he relies. 

Claim 8 

With respect to claim 8, Weicha's reference at Col. 3, 
lines 10-18 is of the end user accessing the catalog from 
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the production tables, not of the administrator (that is, 
applicants "buyer" ) accessing and modifying (in a controlled 
manner, that is, enabling change to selected fields) the 
catalog while still in the staging tables. Applicants claim 
8 states: 

"presenting a graphical user interface to said buyer 
containing said catalog data and enabling said buyer to 
change selected fields of data in said staging 
table. . ." 

As previously discussed with respect to claim 1, applicants' 
"buyer" is not the end user, or Wiecha's "employee". 

Further, Weicha's reference at Col. 2, lines 4-19 does 
not indicate, as applicants claim, that the buyer 
(administrator) actually controls when the data is moved 
from the staging area into the production area, where it 
then becomes accessible to the end users for creating 
requisitions . 

Claims 9-10 

Claims 9 and 10 depend from claim 8, and are 
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distinguished from Weicha (and Anderson) as previously 
described . 

Further with respect to claim 9, Weicha is describing 
purchase order change and purchase order cancel EDI 
transactions. Applicants invention involves automatic 
electronic notification to the supplier when the catalog 
data provided is in an improper format, or when for some 
other reason it fails to load to the staging table. 

Further with respect to claim 10, Weicha is describing 
the user's ability to update a purchase order. This is not 
the same as in applicants invention, which provides an 
administrative user (buyer) a level of authority to be 
granted to him that allows him to modify certain attributes 
of the catalog data. 

Claims 12 and 14 

Claims 12 and 14 are similar in scope to claim 1, and 
are distinguished from Wiecha as previously discussed with 
respect to claim 1. Specifically, with respect to claims 12 
and 14, Wiecha' s teachings at Col. 9, lines 2-10 and Col. 8, 
lines 35-36, relate to the end user ordering from the 
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a I. ■• 

catalog, not to the administrator (buyer) accessing the 
staging table. 



Claim 13 



Claim 13 is similar in scope to claim 8, and is 
distinguished from Wiecha as previously discussed with 
respect to claim 8. Specifically, Wiecha' s reference at 
Col. 3, lines .10-18 is of the end user accessing the catalog 
from the production tables, not of the administrator 
accessing and modifying (in a controlled manner) the catalog 
while still in the staging tables. Wiecha' s reference at 
Col. 2, lines 4-19 do not indicate that the buyer 
(administrator) actually controls when the data is moved 
from the staging area into the production area, where it 
then becomes accessible to the end users for creating 
requisitions. Further, with respect to claims 13 and 14, in 
Anderson, ACH PPD is a type of invoice information, not a 
flat file format. See Col. 3, lines 16-20. 



Claims 15-16 



Claims 15 and 16 depend from claim 13, are similar in 
scope to claims 9 and 10 and are distinguished from Wiecha 
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as discussed with respect to claim 9, 10, and 13. 



SUMMARY AND CONCLUSION 



Applicants urge that the above amendments be entered 
and the case passed to issue with claims 1-16. 

The Application is believed to be in condition for 
allowance and such action by the Examiner is urged. Should 
differences remain, however, which do not place one/more of 
the remaining claims in condition for allowance, the 
Examiner is requested to phone the undersigned at the number 
provided below for the purpose of providing constructive 
assistance and suggestions in accordance with M.P.E.P. 
Sections 707.02 (j) and 707.03 in order that allowable claims 
can be presented, thereby placing the Application in 
condition for allowance without further proceedings being 

END920000110US1 42 of 43 S/N 09/657,196 



necessary. 



Sincerely, 

D. G . Ruest, et al . 

By 




Reg. No. 24,886 

Date: 1 Oct 2004 

Shelley M Beckstrand, P.C. * 
Attorney at Law 
61 Glenmont Road 
Woodlawn, VA 24381 

Phone: (276) 238-1972 



END920000110US1 



43 of 43 



S/N 09/657,196 



